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ABSTRACT 

We present in this study an integrated systems design for a VLSI multipro- 
cessor capable of generating contour surface displays in real-time (one-thirtieth of 
a second}. We begin by examining an application that requires real-time contour 
surface display generation |10.. We sketch some outlines for an architecture 
based upon a decomposable algorithm recently published |l2l. We then propose 
an architecture for a single board \’LSI contour surface display generator that is 
pluggable into the Multibus of the Silicon Graphics, Inc, IRIS workstation. 

Categories and Subject Descriptors: 1 3.1 [Hardware Architecture]: architec- 
tures. parallel processing. VLSI implementations; 1.3.2 [Graphics Systems]: 
multiprocessing systems: 13.5 [Computational Geometry and Object 

Modeling]: data structures, discrete planar contours, modeling molecules, surface 
approximation, surface generation, surface representation, surfaces, 3D graphics; 
1.3.6 [Methodology and Techniques]: contouring, interactive systems, parallel 
processing: 1.3.7 [Three-Dimensional Graphics and Realism]: line drawings, 
line generation algorithms, real-time graphics, surface plotting, surface visualiza- 
tion, surfaces; 1.3. m [Miscellaneous]: VLSI; 

General Terms: Algorithms, architecture; 

-Additional Key Words and Phrases, contouring, contouring tree, contour surface 
display generation, real-time display generation; 



1. Introduction 

Contour surface display generation is one of the most frequently used applications graphics 
algorithms 1. 3. J<-16 . A contour surface display is a visual representation of a surface b> the 
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collection of lines formed when that surface is intersected by a set of parallel planes (Figure 1). 
The lines formed on each of those planes are called contours. A contour represents the set of 
points that belong to both the surface and the particular intersecting plane. Contour surface 
displays are used in X-ray crystallography, computer-aided tomography, and other applications 
for which grid data is collected. Contour surface display generation is generally depicted as a 
computationally slow operation whose output is sent to a plotter or film recorder. One publica- 
tion has described an architecture, and produced a feasibility determination for a VLSI based con- 
tour surface display generator |10]. The architecture proposed in that study, while appropriate for 
its level, does not provide enough detail for actual implementation. .Neither does that study con- 
sider some of the issues that occur when one actually designs a working system. This study 
attempts to remedy those deficiencies by providing an integrated systems architecture for a real- 
time contour surface display generator that is both precise in detail, and technologically realistic. 

1.1. Contour Surface Display Generation is Slow 

Our initial premise for this study is that contour surface display generation on a single pro- 
cessor system, such as a graphics workstation with a floating point accelerator, is too slow to be of 
an> use for interactive applications requiring such a display. This premise is based upon 10’, and 
is reinforced by statements found in the literature. A number of papers have been written docu- 
menting ’’breakthroughs” that increase the speed of contour surface display generation. One 
author has reported that his contour surface display generation subroutine used one second of cen- 
tral processor time on NC.AR’s Control Data 7600 9 . Although a contour surface display genera- 
tion program of this speed is useful for static situations, it is unacceptable for applications that 
generate a succe.ssion of contour surface displays in response to contour level changes read from a 
control dial. Such a program requires that a new contour surface display be generated, distri- 
buted. and displayed in real-time, typically one-thirtieth of a second for current display technol- 
ogy 6 

One application in which real-time contour surface display generation is important is the 
determination of molecular structures from the electron density data generated by X-ray 
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crystallography |lj. Such an operation is executed interactively by using a computer graphics 
program that displays a Dreiding (stick) model of the molecule inside a contour surface display of 
the corresponding region of the molecule’s electron density grid. In addition to the graphics func- 
tion, the computer program monitors a series of signals generated by the user, while the user is 
turning the various knobs on a control console |17). The values read from these knobs are inter- 
preted by the program as modifications to either the molecule or the surface display. Modifica- 
tions to the molecule take the form of bond rotations or bond lengthenings. Modifications to the 
contour surface display take the form of an increase or decrease of the contour level. The goal of 
this process is to produce the stick model of the molecule that best fits inside the given electron 
density data set. The user can determine whether or not the model fits the density grid by modi- 
fying the contour level, shrinking the contour surface to the molecule. Similarly, the user can 
expand the contour surface from the stick model for better visibility. This function requires that 
the hardware have the capability to rapidly change the contour display as its contour level 
changes. 

VVe know from jl3] that the generation of a contour surface display, such as those required 
by the above application, cannot be accomplished in real-time using a conventional uniprocessor. 
This failure is due to the fact that contour surface display generation algorithms require many 
more instructions executed per second than can be provided by currently available uniprocessors. 
In the past, this limitation of the conventional processor has relegated such applications to either 
the non real-time environment (waiting a few minutes for each display), or to the equally unsatis- 
fying environment of motion picture film. Because of this, the author of '10 looked for a mul- 
tiprocessor solution to the real-time contour surface display generation problem. At the time of 
that study, efficient multiprocessor solutions meant VLSI solutions. Consequently, the multipro- 
cessor architecture proposed in that study was qualified by the need for implementation in \'LS1. 
This study continues with that qualification. 



A 2 X 2 Subgrid 



2 



1 

1 2 ... 1 

A 2D Grid of Size 1 x m Has 
(1 - 1) X (m - 1) 2x2 Subgrids. 




A 3D Grid of Size 1 x m x n Has 

1 X (m - 1) X (n - 1) + m X (1 - 1) X (n - 1) + n X (1 - 1) X (m - 1) 

2x2 Subgrids 

Figure 2 

2x2 Subgrid Count for 2D and 3D Grids 



- 4 - 



1.2. Contouring Definitions 

A contour surface is a visual display that represents all points in a particular region of 
three-space <x,y,z> which satisfy the relation f(<x,y,z>) = k, where k is a constant known as the 
contour level (Figure 1). The function f represents a physical quantity which is defined over the 
three-dimensional volume of interest. The visual display created by this algorithm is the collec- 
tion of lines that belong to the intersection of both the set of points that satisfy the relation 
f(<x,y,z>)= k. and a set of regularly spaced parallel planes that pass through the region of three- 
space for which the relation is defined. 

For this study, the function f is approximated by a discrete, three-dimensional grid created 
by sampling that function over the volume of interest. The three-dimensional grid contains a 
value at each of its defined points that corresponds to the physical quantity obtained from the 
function, i.e. the value associated with point (x^.y^.z^) is v^, where n^Qiyo’*o^~'^0' 

A decomposable algorithm for contour surface display generation is described in 12]. That 
algorithm is constructed from a two-dimensional contouring algorithm that is used to contour all 
the possible planar, orthogonal, two-dimensional grids of a larger three-dimensional grid. The 
two-dimensional contouring algorithm of that study is comprised of components, called algorithm 
components, that operate on individual 2x2 subgrids of a larger two-dimensional grid. (Note: a 
2x2 subgrid is defined to be that portion of the two-dimensional grid bounded by four adjacent 
grid points.) In the algorithm, the computations necessary for generating the contour lines for a 
single 2x2 subgrid are independent from those required for any other 2x2 subgrid. If we com- 
pute the contours corresponding to contour level k for all 2x2 subgrids of a two-dimensional 
grid, then we will have determined the complete set of contours for that grid. If we compute the 
contours corresponding to contour level k for all possible 2x2 subgrids of the larger three- 
dimensional grid, then we will have the complete contour surface display for that grid. The 
assemblage of the contours created by this process, i.e. the simultaneous display of all the con- 
tours created for all 2 x 2 subgrids of the larger three-dimensional grid, produces a "chicken-wire- 
like" contour surface display (Figure l). The full development of this algorithm can be found in 



1 11- 13 . We refer to the results of those studies, and consequently, do not cover the algorithm 
here in great detail We only note that for the largest three-dimensional grid of interest for the 
above application, a 30 x 30 x 30 grid, this means the potential for 75,690 parallel operations (see 
Figure 2 and l]). 

2. Architectural Goals for the Contour Surface Display Generator 

The first goal in the design of the contour surface display generator is to build a system that 
meets the performance requirements, i.e. a new contour surface display computed from a 
30 X 30 X 30 grid, and delivered to a display de\ ice in one-thirtieth of a second. This is an ambi- 
tious goal but it must be noted that one-thirtieth of a second is the maximum amount of time 
allowable for the operation. Any longer amount of time does not provide the viewer smooth tran- 
sitions between successive contour surface displays. This goal says nothing about the load time of 
the 30 X 30 x 30 grid to the special piece of hardware that computes the contour surface display. 
Consequently, we allow solutions that pre-load the grid. 

The second goal for the construction of the contour surface display generator is that we be 
able to plug it into an existing graphics system with minimal hardware and software changes. For 
the purposes of this study, the target graphics system is chosen to be the Silicon Graphics, Inc. 
IRIS workstation (see Figure 3 and 2 ). The Silicon Graphics, Inc. IRIS is currently the highest 
performance graphics system that best matches the selected application’s goals. 

3. Architecture of the ('ontour Surface Display Generator 

There is not enough space in this paper to present the complete architecture of the contour 
surface display generator. The reader is instead referred to 8 . An overview architectural 
description is that the contour surface display generator is comprised of four subsystems (1) the 
array of algorithm component process< rs. (2) the controller for that array of processors. (3) the 
algorithm component processor itself, and (4) the interface to the graphics system. Figure 4 
shows how the four subsystems relate to the target graphics system. 
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Figure 4 depicts the array of algorithm component processors as a single box, with three 
connections to ihe outside environment: an input bus for contour levels and subgrids, an output 
bus for coordinates and drawing instructions, and a bus for controlling the array of processors. A 
dual bus configuration is chosen l.o maximize the amount of concurrency in the system due to the 
autonomous nature of the input with respect to the output. 

The input bus is the medium responsible for delivering subgrid definitions and contour levels 
to the array of algorithm component processors. Because this is the only data required to be 
transmitted on the bus, the bandwidth of the input bus does not need to be very high. The rate 
at which subgrid definitions are loaded into the algorithm component processors does not directly 
affect the real-time capabilities of the system. The real-time capabilities of the contour surface 
display generator are determined by the rate at which data can be produced in each algorithm 
component processor. This, in turn, directly affects the rate of output to the display processing 
unit. The output bus is responsible for delivering the coordinates and drawing instructions to the 
display processing unit. 

The control bus for the contour surface display generator contains all the control lines neces- 
sary to manage the data flow on the input side of the system. Two additional control lines are 
required on the output side of the system to coordinate the two wire handshake between the algo- 
rithm component processors and the display processing unit (Geometry Engines). 

Control of the array of algorithm component processors involves the integration of several 
different components. The one which coordinates the operation of all other components is the 
systems controller (F'igure o). The systems controller converts incoming signals from the .Mul- 
tibus bus master of the Silicon Graphics. Inc. IRIS workstation into signals which make sense to 
the algorithm component processors. The Multibus bus master is the board in the .Multibus 
Backplane which places the commands on the Multibus. The systems controller is a slave in that 
it reacts to commands placed on the Multibus. 

The component that is responsible for the production of the coordinates and drawing 
instructions for the contour surface display generator is the algorithm component processor 
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(Figure 5). Each of these processors is identical and functions independently in the production of 
the outputs. V\e do not go into great detail about that processor other than to state that the pro- 
cessor is a full microprocessor of the Motorola MC68000 class. 

The contour surface display generator is connected to the Silicon Graphics, Inc. IRIS graph- 
ics system by means of the IEEE standard Multibus Backplane Bus j4i. This Multibus connection 
provides all inputs to the contour surface displa> generator. The Multibus interfaces to basically 
two different classifications of bus modules: (l) Masters - those modules which generate com- 
mands, and (2) Slaves - those which respond to commands. The parent processor (MC68000) is 
the Master module for the graphics system. The contour surface display generator is a slave 
module in that system. 

The output of the contour surface display generator is to the Private Bus of the IRIS system 
(Figures 3 and 6). The Private Bus is a unidirectional, 16 bit bus dedicated to the provision of 
coordinate and drawing instructions to the high speed (Geometry Engines. C-oordination of the 
transfer of data between the algorithm component processors and the Geometry Engines is done 
via a two line handshake protocol. 

When the contour surface display generator is added to the system, a physical connection to 
the (Jeometry Engine pipeline must be shared by both itself and the system processor (the J3 con- 
nection of the Geometry Engine board). To enable the user to alternatively route processor and 
generator data to the Geometry Engines, a hardware switch is added to the system This 
hardware provides the system with a way to multiplex the direct path of the Private Bus A 
software switch then provides the control of the Private Bus' origin and configuration. When 
activated, this switch establishes a path from the contour surface display generator. If it is not 
activated, the IRIS system remains in its original configuration. 

4. Hardware Complexity Estimate 

The above is a quick overview of the architecture of the contour surface display generator. 
One of the key components in this system is obviously the algorithm component processor. In 8 . 
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it is determined that 50 algorithm component processors are all that are needed in the system to 
generate and deliver the average sized picture for a 30 x 30 x 30 grid. In order to determine the 
feasibility of the complete system, we need a circuit complexity estimate for the size of the algo- 
rithm component processor. In [8], we find a summary of the number of transistor equivalent 
devices necessary. We note only that the total number of devices required for one algorithm com- 
ponent processor is about 660K devices. This number is well below the two million devices per 
chip level that is currently being produced in research laboratories |5]. For this level of chip com- 
plexity, the array of algorithm component processors can be built in less than 25 VLSI chips. At 
the ten million devices per chip level promised in [7 , this is less than 5 VLSI chips. The design of 
this system is therefore within the grasp of current technology. 

5. Conclusions 

This study is intended to give a clearer system description of the elements comprising the 
contour surface display generator. Some of the deficiencies of earlier research were remedied by 
defining the control lines of the system. The technological feasibility of the system’s implementa- 
tion is established in two ways. The first is that a realistic number of algorithm component pro- 
cessors is established (50). The second is that the circuit complexity of the algorithm component 
processor chip is shown to be within the capabilities of current VLSI technology. 

We can be assured that once we produce such a system that the applications user will 
return to us with further hardware demands for either other algorithms, or additional real-time 
graphics display generation capabilities. In order to respond to these desires for special hardware 
for select applications graphics algorithms, we need to either justify the special hardware effort on 
the basis of widespread demand, or make the production of that special hardware inexpensive. 
V\e cannot count on the widespread demand for any algorithm for which we desire real-time per- 
formance. The only solution then is to make the production of that special hardware inexpensive. 
The first step in that process is to put together a methodology based upon experience with design- 
ing such special purpose display generators. Once that methodolog\ is sufficiently developed, we 
can then set standards for the production of such systems. We can see an analogy in the world of 
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VLSl design. The design and production of special VLSI chips came within the possibilities of the 
university community after standard interfaces were defined for chip production. Hence, we saw 
the establishment of "silicon foundries". If we e.xtend this idea to that of the production of spe- 
cial hardware for select graphics algorithms of the applications user, this means that somewhere in 
the future there will be "real-time, graphics foundries". It is towards this direction that we can 
expect future developments in hardware graphics capabilities to proceed. 
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